home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / g_man / cat3 / standard / pixmode.z / pixmode
Encoding:
Text File  |  2002-10-03  |  27.9 KB  |  529 lines

  1.  
  2.  
  3.  
  4. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      ppppiiiixxxxmmmmooooddddeeee - specify pixel transfer mode parameters
  10.  
  11. CCCC SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNN
  12.      vvvvooooiiiidddd ppppiiiixxxxmmmmooooddddeeee((((lllloooonnnngggg mmmmooooddddeeee,,,, lllloooonnnngggg vvvvaaaalllluuuueeee))))
  13.  
  14. PPPPAAAARRRRAAAAMMMMEEEETTTTEEEERRRRSSSS
  15.      _m_o_d_e    One of the symbolic constants:
  16.  
  17.  
  18.           (parameters that affect read, write, and copy transfers)
  19.  
  20.              PPPPMMMM____SSSSHHHHIIIIFFFFTTTT, default value: 0.  Number of bit positions that pixel
  21.              data are to be shifted.  Positive shifts are left for write and
  22.              copy, right for read.  Valid values: 0, +-1, +-4, +-8, +-12, +-
  23.              16, +-24
  24.  
  25.              PPPPMMMM____EEEEXXXXPPPPAAAANNNNDDDD, default value: 0.  Enable (1) or disable (0) expansion
  26.              of single-bit pixel data to one of two 32-bit pixel values.
  27.              Valid values: 0, 1
  28.  
  29.              PPPPMMMM____CCCC0000, default value: 0.  Expansion value (32-bit packed color)
  30.              chosen when the single-bit pixel being expanded is zero.  Valid
  31.              values: any 32-bit value
  32.  
  33.              PPPPMMMM____CCCC1111, default value: 0.  Expansion value (32-bit packed color)
  34.              chosen when the single-bit pixel being expanded is one.  Valid
  35.              values: any 32-bit value
  36.  
  37.              PPPPMMMM____AAAADDDDDDDD22224444, default value: 0.  Amount to be added to the least-
  38.              significant 24 bits of the pixel (signed value).  Valid values: a
  39.              32-bit signed value in the range -0x800000 through 0x7fffff
  40.  
  41.              Although this value is specified as a 32-bit integer, the sign
  42.              bit MUST be smeared across all 32 bits.  Thus -0x800000 specifies
  43.              the minimum value; and 0x800000 is out of range at the positive
  44.              end.
  45.  
  46.              PPPPMMMM____TTTTTTTTOOOOBBBB, default value: 0.  Specifies that fill (for write and
  47.              copy transfers) and read (for read transfers) must be top-to-
  48.              bottom (1) or bottom-to-top (0).  Valid values: 0, 1 (see NOTES
  49.              below)
  50.  
  51.              PPPPMMMM____RRRRTTTTOOOOLLLL, default value: 0.  Specifies that fill (for write and
  52.              copy transfers) and read (for read transfers) is to be right-to-
  53.              left (1) or left-to-right (0).  Valid values: 0, 1
  54.  
  55.              PPPPMMMM____IIIINNNNPPPPUUUUTTTT____FFFFOOOORRRRMMMMAAAATTTT,,,, PPPPMMMM____OOOOUUUUTTTTPPPPUUUUTTTT____FFFFOOOORRRRMMMMAAAATTTT, default values: PM_ABGR. If in
  56.              RGBmode, specifies the pixel color component format; if in cmode,
  57.              has no effect. The format specifies the number and order of color
  58.              components. May be one of: PM_ABGR, PM_BGR, PM_RGBA, PM_RGB,
  59.              PM_LUMINANCE, PM_LUMINANCEA, PM_ALPHA. If PM_LUMINANCE or
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  71.  
  72.  
  73.  
  74.              PM_LUMINANCEA is selected as the PM_OUTPUT_FORMAT, all of the
  75.              other features of ppppiiiixxxxmmmmooooddddeeee will be ignored except for
  76.              PM_INPUT_TYPE, PM_OUTPUT_TYPE, PM_OFFSET, and PM_STRIDE.
  77.  
  78.              PPPPMMMM____IIIINNNNPPPPUUUUTTTT____TTTTYYYYPPPPEEEE, default values: PM_UNSIGNED_BYTE. Specifies the
  79.              type of pixel color components.  May be one of: PM_BITMAP,
  80.              PM_BYTE, PM_UNSIGNED_BYTE, PM_SHORT_12, PM_UNSIGNED_SHORT_12,
  81.              PM_SHORT, PM_UNSIGNED_SHORT, PM_INT, PM_UNSIGNED_INT, PM_FLOAT.
  82.  
  83.              PPPPMMMM____OOOOUUUUTTTTPPPPUUUUTTTT____TTTTYYYYPPPPEEEE, default values: PM_UNSIGNED_BYTE. Specifies the
  84.              type of pixel color components.  May be one of: PM_BITMAP,
  85.              PM_UNSIGNED_BYTE, PM_UNSIGNED_SHORT_12, PM_UNSIGNED_SHORT,
  86.              PM_UNSIGNED_INT, PM_FLOAT.
  87.  
  88.  
  89.           (parameters that affect read and write transfers only)
  90.  
  91.              PPPPMMMM____SSSSIIIIZZZZEEEE, default value: 32.  Number of bits per pixel.  Used for
  92.              packing during reads and writes.  Valid values: 1, 4, 8, 12, 16,
  93.              24, 32, 64 (see NOTES below)
  94.  
  95.              Although size specification is for the entire pixel, there is no
  96.              mechanism for specifying reduced RGBA component sizes (such as
  97.              12-bit RGB with 4 bits per component) except as in NOTES below.
  98.  
  99.              PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT, default value: 0.  Number of bits of the first CPU
  100.              word of each scanline that are to be ignored.  Valid values: 0
  101.              through 31
  102.  
  103.              PPPPMMMM____SSSSTTTTRRRRIIIIDDDDEEEE, default value: 0.  Number of 32-bit CPU words per
  104.              scanline in the original image (not just the portion that is
  105.              being transferred by this command).  Valid values: any non-
  106.              negative integer
  107.  
  108.  
  109.           (parameters that affect write and copy transfers only)
  110.  
  111.              PPPPMMMM____ZZZZDDDDAAAATTTTAAAA, default value: 0.  Indicates (1) that pixel data are to
  112.              be treated as Z data rather than color data (0).  Destination is
  113.              the Z-buffer.  Writes are conditional if zbuffering is on.  Valid
  114.              values: 0, 1
  115.  
  116.      _v_a_l_u_e   Integer value assigned to mode.
  117.  
  118. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  119.      ppppiiiixxxxmmmmooooddddeeee allows a variety of pixel transfer options to be selected.  These
  120.      options are available only for pixel transfer commands that operate on
  121.      32-bit data: llllrrrreeeeccccttttrrrreeeeaaaadddd, llllrrrreeeeccccttttwwwwrrrriiiitttteeee, and rrrreeeeccccttttccccooooppppyyyy. Pixel transfer commands
  122.      that operate on 8-bit data (rrrreeeeaaaaddddRRRRGGGGBBBB, wwwwrrrriiiitttteeeeRRRRGGGGBBBB) and on 16-bit data
  123.      (rrrreeeeaaaaddddppppiiiixxxxeeeellllssss, wwwwrrrriiiitttteeeeppppiiiixxxxeeeellllssss, rrrreeeeccccttttrrrreeeeaaaadddd, rrrreeeeccccttttwwwwrrrriiiitttteeee) do not support ppppiiiixxxxmmmmooooddddeeee
  124.      capabilities.  Note that llllrrrreeeeccccttttrrrreeeeaaaadddd, llllrrrreeeeccccttttwwwwrrrriiiitttteeee, and rrrreeeeccccttttccccooooppppyyyy are valid in
  125.      both color map and RGB modes.
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  137.  
  138.  
  139.  
  140.      PPPPaaaaddddddddiiiinnnngggg iiiinnnn CCCCPPPPUUUU MMMMeeeemmmmoooorrrryyyy
  141.  
  142.      Transfer commands llllrrrreeeeccccttttrrrreeeeaaaadddd and llllrrrreeeeccccttttwwwwrrrriiiitttteeee operate on pixel data
  143.      structures in CPU memory.  These data structures contain data organized
  144.      in row-major format, each row corresponding to one scanline of pixel
  145.      data.  Adjacent pixels are packed next to each other with no padding,
  146.      regardless of the pixel size.  Thus in many cases pixels straddle the
  147.      32-bit word boundaries.  It is always the case, however, that each scan
  148.      line comprises an integer number of whole 32-bit words.  If the pixel
  149.      data do not exactly fill these words, the last word is padded with
  150.      (undefined) data.
  151.  
  152.      Addresses passed to llllrrrreeeeccccttttrrrreeeeaaaadddd and llllrrrreeeeccccttttwwwwrrrriiiitttteeee must be long word aligned.
  153.      If not, an error message is generated and no action is taken.
  154.  
  155.      PPPPaaaacccckkkkiiiinnnngggg iiiinnnn CCCCPPPPUUUU MMMMeeeemmmmoooorrrryyyy
  156.  
  157.      Transfer commands llllrrrreeeeccccttttrrrreeeeaaaadddd and llllrrrreeeeccccttttwwwwrrrriiiitttteeee operate on pixel data that are
  158.      packed tightly into CPU memory.  Adjacent pixels, regardless of their
  159.      size, are stored with no bit padding between them.  Pixel size, and thus
  160.      packing, is specified by PPPPMMMM____SSSSIIIIZZZZEEEE.  The default value of this parameter is
  161.      32, meaning that 32-bit pixels are packed into 32-bit CPU memory words.
  162.  
  163.      Although the MIPS processor is a big-endian machine, its bit numbering is
  164.      little-endian.  Pixel data are packed consistent with the byte numbering
  165.      scheme (big-endian), ignoring the bit numbering.  Thus, 12-bit packed
  166.      pixels are taken as follows (by llllrrrreeeeccccttttwwwwrrrriiiitttteeee) from the first 32-bit word of
  167.      a CPU data structure:
  168.  
  169.   first CPU word
  170.  
  171.           byte number  0        1        2        3
  172.  
  173.           bit number   33222222 22221111 111111
  174.                        10987654 32109876 54321098 76543210
  175.  
  176.   first unpacked pixel 11
  177.                        10987654 3210
  178.   second unpacked pixel             11
  179.                                     1098 76543210
  180.   third unpacked pixel                           11
  181.                                                  10987654 ...
  182.  
  183.  
  184.      When being written, unpacked pixels are padded to the left with zeros to
  185.      make their size equal to the size of the framebuffer target region (12
  186.      bits total in color map mode, 24 bits total when writing Z values, 32
  187.      bits total in RGB mode).  The least significant bit of the unpacked pixel
  188.      becomes the least significant bit of the framebuffer pixel it replaces.
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  203.  
  204.  
  205.  
  206.      Note that big-endian packing makes 8 and 16 bit packing equivalent to
  207.      character and short arrays.  Remember, however, that the address passed
  208.      to llllrrrreeeeccccttttwwwwrrrriiiitttteeee or llllrrrreeeeccccttttrrrreeeeaaaadddd must be long-word aligned.
  209.  
  210.      Packings of 1, 4, 8, 12, 16, 24, and 32 bits per pixel are supported.
  211.      Setting PPPPMMMM____SSSSIIIIZZZZEEEE to a value other than one of these results in an error
  212.      message, and leaves the current size unchanged.
  213.  
  214.      OOOOrrrrddddeeeerrrr ooooffff PPPPiiiixxxxeeeellll OOOOppppeeeerrrraaaattttiiiioooonnnnssss
  215.  
  216.      In addition to packing and unpacking, pixel streams are operated on in a
  217.      variety of other ways.  These operations occur in a consistent order,
  218.      regardless of whether the stream is being written, read, or copied.
  219.  
  220.           write unpack->shift->expand->add24->zoom->fbpack
  221.           copy  format->shift->expand->add24->zoom->fbpack
  222.           read  format->shift->expand->add24      ->pack
  223.  
  224.  
  225.      Note that pixel data are unpacked only when being transferred from CPU
  226.      memory to the framebuffer.  Unpacking occurs prior to any other
  227.      operation.  Likewise, pixel data are packed only when being transferred
  228.      to CPU memory.  Packing occurs after all other operations have been
  229.      completed.  Because copy operations neither pack nor unpack pixel data,
  230.      the rectcopy command ignores the value of PPPPMMMM____SSSSIIIIZZZZEEEE....
  231.  
  232.      FFFFrrrraaaammmmeeeebbbbuuuuffffffffeeeerrrr FFFFoooorrrrmmmmaaaatttt
  233.  
  234.      Each IRIS framebuffer is always configured in one of two fundamental
  235.      ways: color map or RGB.  In the RGB configuration 3 or 4 color components
  236.      (red, green, blue, and optionally alpha) are stored at each pixel
  237.      location.  Each component is stored with a maximum of 8 bits of
  238.      precision, resulting in a packed 32-bit pixel with the following format:
  239.  
  240.               33222222 22221111 111111
  241.               10987654 32109876 54321098 76543210
  242.  
  243.               aaaaaaaa bbbbbbbb gggggggg rrrrrrrr
  244.               76543210 76543210 76543210 76543210
  245.  
  246.  
  247.  
  248.      Some IRIS framebuffers store fewer than 8 bits per color component while
  249.      in RGB mode.  These framebuffers, however, emulate all the behavior of
  250.      full 32-bit framebuffers.  Thus the first operation in both the copy and
  251.      read streams (above) is format: converting the framebuffer-format data to
  252.      the 8-bit per component RGBA format that all subsequent operations
  253.      execute with.  Likewise, the final operation in both the write and copy
  254.      streams (above) is fbpack: converting the 8-bit per component RGBA data
  255.      back to the hardware-specific storage format.  Both the format and the
  256.      fbpack operation are null operations if the hardware supports full 32-bit
  257.      RGBA data.
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  269.  
  270.  
  271.  
  272.      In its color map configuration a single color index, from 1 to 12 bits,
  273.      is stored at each pixel location:
  274.  
  275.           33222222 22221111 111111
  276.           10987654 32109876 54321098 76543210
  277.  
  278.                                 iiii iiiiiiii
  279.                                 11
  280.                                 1098 76543210
  281.  
  282.  
  283.  
  284.      PPPPiiiixxxxeeeellll SSSShhhhiiiiffffttttiiiinnnngggg
  285.  
  286.      Pixels taken from the framebuffer (llllrrrreeeeccccttttrrrreeeeaaaadddd, rrrreeeeccccttttccccooooppppyyyy) or unpacked from
  287.      CPU memory (llllrrrreeeeccccttttwwwwrrrriiiitttteeee) are first rotated either left or right by an
  288.      amount up to 24 bit positions.  Unpacked pixels and pixel values to be
  289.      packed are padded left and right by zeros during the shift operation.
  290.      The resulting 32-bit pixel values therefore include ones only in the
  291.      region that was filled with legitimate pre-shifted data.  Copied pixels
  292.      may not be padded with zeros; thus a writemask may be required to
  293.      eliminate unwanted bits.
  294.  
  295.      Pixel shifting is enabled by setting PPPPMMMM____SSSSHHHHIIIIFFFFTTTT to a non-zero value.
  296.      Positive values in the range 1-24 specify left shifts while writing or
  297.      copying, right shifts while reading.  Negative values in the range -1
  298.      through -24 specify right shifts while writing or copying, left shifts
  299.      while reading.
  300.  
  301.      The default shift value is zero (i.e. shifting disabled).  Other accepted
  302.      values are plus and minus 1, 4, 8, 12, 16, and 24.
  303.  
  304.      Because pixels are always converted to the formats described above before
  305.      they are shifted, shift operations are largely independent of the
  306.      hardware framebuffer storage format.
  307.  
  308.      PPPPiiiixxxxeeeellll EEEExxxxppppaaaannnnssssiiiioooonnnn
  309.  
  310.      Single bit pixels can be expanded to one of two full 32-bit color values,
  311.      based on their binary value.  This expansion is enabled by setting
  312.      PPPPMMMM____EEEEXXXXPPPPAAAANNNNDDDD to 1 (the default disabled value is 0).  When expansion is
  313.      enabled, zero value pixels are replaced by the packed color PPPPMMMM____CCCC0000, and
  314.      one value pixels are replaced by PPPPMMMM____CCCC1111.  Bits 11-0 of PPPPMMMM____CCCC0000 and PPPPMMMM____CCCC1111
  315.      specify color index values when in color map mode.
  316.  
  317.      Pixel expansion is actually controlled by bit zero of the incoming pixel
  318.      (regardless of the size of the incoming pixel).  Because pixel shifting
  319.      precedes pixel expansion, any bit of the incoming pixel can be selected
  320.      to control pixel expansion.
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.                                                                         PPPPaaaaggggeeee 5555
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  335.  
  336.  
  337.  
  338.      There are no constraints on the values of PPPPMMMM____CCCC0000 or PPPPMMMM____CCCC1111.
  339.  
  340.      PPPPiiiixxxxeeeellll AAAAddddddddiiiittttiiiioooonnnn
  341.  
  342.      The pixel addition stage treats the lower 24 bits of each incoming pixel
  343.      as  a signed integer value.  It adds a signed 24-bit constant to this
  344.      field of the pixel, leaving the upper 8 bits unchanged.  The result of
  345.      the addition is clamped to the range -2 through 2 - 1.  While this
  346.      addition is most useful when writing or copying depth data, it is enabled
  347.      during all transfers.  Thus PPPPMMMM____AAAADDDDDDDD22224444 is typically changed from its
  348.      default zero value only while depth transfers are being done (See
  349.      "Drawing Z Data" below).  Pixel addition can also be used to offset the
  350.      range of a color map image.
  351.  
  352.      RRRReeeeccccttttaaaannnngggglllleeee wwwwiiiitttthhhhiiiinnnn RRRReeeeccccttttaaaannnngggglllleeee iiiinnnn CCCCPPPPUUUU MMMMeeeemmmmoooorrrryyyy
  353.  
  354.      Variables PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT and PPPPMMMM____SSSSTTTTRRRRIIIIDDDDEEEE support transfer operation on
  355.      rectangular pixels regions that reside within larger regions in CPU
  356.      memory.  PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT, set to a value in the range 0-31, specifies the
  357.      number of significant bits of the first CPU word that are ignored at the
  358.      start of each scanline transfer.  For example, an llllrrrreeeeccccttttwwwwrrrriiiitttteeee transfer of
  359.      12-bit packed pixel data with PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT set to 12 results in the
  360.      following pixel extraction:
  361.  
  362.   first CPU word of each scanline
  363.  
  364.        byte number         0        1        2        3
  365.  
  366.        bit number      33222222 22221111 111111
  367.                        10987654 32109876 54321098 76543210
  368.  
  369.   first unpacked pixel              11
  370.                                     1098 76543210
  371.   second unpacked pixel                           11
  372.                                                   10987654 ...
  373.  
  374.  
  375.      Pixel unpacking continues tightly throughout all the CPU words that
  376.      define a single scanline.  After the last CPU word that defines a
  377.      scanline has been transferred, the CPU read pointer is advanced to the
  378.      32-bit word at location (_f_i_r_s_t + PPPPMMMM____SSSSTTTTRRRRIIIIDDDDEEEE).  PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT pixels of this
  379.      word are skipped, then this scanline is transferred to the graphics
  380.      engine.  The PPPPMMMM____SSSSTTTTRRRRIIIIDDDDEEEE value of zero is exceptional, causing the CPU read
  381.      pointer to be advanced to the 32-bit word that immediately follows the
  382.      last word of each scanline.
  383.  
  384.      PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT and PPPPMMMM____SSSSTTTTRRRRIIIIDDDDEEEE, like PPPPMMMM____SSSSIIIIZZZZEEEE, are ignored by framebuffer-to-
  385.      framebuffer transfers (rrrreeeeccccttttccccooooppppyyyy). They both default to a value of zero.
  386.  
  387.      AAAAlllltttteeeerrrrnnnnaaaatttteeee FFFFiiiillllllll DDDDiiiirrrreeeeccccttttiiiioooonnnnssss
  388.  
  389.  
  390.  
  391.  
  392.  
  393.                                                                         PPPPaaaaggggeeee 6666
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  401.  
  402.  
  403.  
  404.      During read, copy, and write pixel operations pixels are always
  405.      transferred in row-major order.  By default scanlines are read or written
  406.      left-to-right, starting with the bottom scanline and working up.
  407.      Parameters PPPPMMMM____RRRRTTTTOOOOLLLL and PPPPMMMM____TTTTTTTTOOOOBBBB allow the horizontal and vertical
  408.      read/fill directions to be reversed, but do not change the fundamental
  409.      row-major scan order.  PPPPMMMM____RRRRTTTTOOOOLLLL specifies right-to-left traversal/fill
  410.      when set to one, left-to-right when set to its default value of zero.
  411.      PPPPMMMM____TTTTTTTTOOOOBBBB specifies top-to-bottom traversal/fill when set to one, bottom-
  412.      to-top when set to its default value of zero.
  413.  
  414.      These parameters can be used to properly deal with CPU data formats that
  415.      differ from the default IRIS pixel order.  They also can be used to
  416.      generate image reflections about either the X or Y screen axes. (see
  417.      notes.)
  418.  
  419.      Fill direction does not affect the location of the destination rectangle
  420.      (i.e. the destination rectangle is always specified by its lower-left
  421.      pixel, regardless of its traversal/fill direction).
  422.  
  423.      DDDDrrrraaaawwwwiiiinnnngggg ZZZZ DDDDaaaattttaaaa
  424.  
  425.      Normally pixel data are treated as colors.  Zbuffer mode must be false
  426.      during llllrrrreeeeccccttttwwwwrrrriiiitttteeee and rrrreeeeccccttttccccooooppppyyyy of color values, because there are no
  427.      source Z values to do the buffer compares with.  Setting PPPPMMMM____ZZZZDDDDAAAATTTTAAAA to 1.0,
  428.      however, instructs the GL to treat incoming pixel values as Z values, and
  429.      to treat source color as undefined.  When drawing pixels with PPPPMMMM____ZZZZDDDDAAAATTTTAAAA
  430.      enabled, the system automatically insures that no changes are made to
  431.      color bitplanes, regardless of the current color write mask.  When
  432.      PPPPMMMM____ZZZZDDDDAAAATTTTAAAA and zzzzbbbbuuuuffffffffeeeerrrr are both enabled, pixel values will be conditionally
  433.      written into the z-buffer in the usual manner, and the color buffer will
  434.      be unaffected.
  435.  
  436.      Z-buffered images are drawn by doing two transfers, first of the Z values
  437.      (with PPPPMMMM____ZZZZDDDDAAAATTTTAAAA enabled and stencil set based on the outcome of the Z
  438.      comparison) and then of the color values (with PPPPMMMM____ZZZZDDDDAAAATTTTAAAA disabled, drawn
  439.      conditionally based on the stencil value).
  440.  
  441.      It is not necessary (or correct) to enable zzzzddddrrrraaaawwww mode while doing pixel
  442.      transfers with PPPPMMMM____ZZZZDDDDAAAATTTTAAAA enabled.
  443.  
  444. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  445.      lrectread, lrectwrite, rectcopy, rectzoom, stencil
  446.  
  447. NNNNOOOOTTTTEEEESSSS
  448.      The Personal Iris, XS, XS24, Elan, XZ and Extreme systems do not support
  449.      ppppiiiixxxxmmmmooooddddeeee during rrrreeeeccccttttccccooooppppyyyy....  IRIS-4D G, GT, GTX, Personal Iris, Indigo
  450.      Entry, Indy, and XL models do not support PM_ZDATA mode.  The Personal
  451.      Iris does not support ppppiiiixxxxmmmmooooddddeeee when reading pixels and supports PPPPMMMM____SSSSIIIIZZZZEEEE
  452.      for values 8, 16, and 32 only.  The Personal Iris, Indigo Entry, Indy,
  453.      and XL support PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT for values that are multiples of PPPPMMMM____SSSSIIIIZZZZEEEE only.
  454.      When reading pixels, XS, XS24, Elan, XZ and Extreme systems do not
  455.      support PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT not equal to 0.  On XS, XS24, Elan, XZ and Extreme
  456.  
  457.  
  458.  
  459.                                                                         PPPPaaaaggggeeee 7777
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466. ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))                                                        ppppiiiixxxxmmmmooooddddeeee((((3333GGGG))))
  467.  
  468.  
  469.  
  470.      systems, you get better pixel fill rate (both write and read) if you
  471.      specify PPPPMMMM____TTTTTTTTOOOOBBBB (top-to-bottom) as the direction of fill.
  472.  
  473.      For writing interlaced fields of video data to the frame buffer, Indy and
  474.      XL systems write every other scan line, bottom-to-top, when PPPPMMMM____TTTTTTTTOOOOBBBB is 2,
  475.      and every other scan line, top-to-bottom, when PPPPMMMM____TTTTTTTTOOOOBBBB is 3.
  476.  
  477.      Indy and XL systems support a 3-3-2 pixel format in a byte (rightmost
  478.      three bits red, next three bits green, and next two bits blue) for
  479.      PPPPMMMM____SSSSIIIIZZZZEEEE of 9.  Indigo Entry systems support a 3-3-2 pixel format in a
  480.      byte (rightmost three bits red, next two bits blue, and next three bits
  481.      green) for PPPPMMMM____SSSSIIIIZZZZEEEE of 8.
  482.  
  483.      PPPPMMMM____SSSSIIIIZZZZEEEE,,,,66664444 is implemented on RealityEngine models only.  Each 64-bit
  484.      pixel contains four 16-bit color components for red (rightmost), green,
  485.      blue, and alpha (leftmost).  Only the upper 12 bits of each component are
  486.      significant.  The lower 4 bits are returned as zero.
  487.  
  488.      PPPPMMMM____OOOOUUUUTTTTPPPPUUUUTTTT____FFFFOOOORRRRMMMMAAAATTTT,,,, PPPPMMMM____OOOOUUUUTTTTPPPPUUUUTTTT____TTTTYYYYPPPPEEEE,,,, PPPPMMMM____IIIINNNNPPPPUUUUTTTT____FFFFOOOORRRRMMMMAAAATTTT,,,, PPPPMMMM____IIIINNNNPPPPUUUUTTTT____TTTTYYYYPPPPEEEE are
  489.      implemented on RealityEngine models only.
  490.  
  491. BBBBUUUUGGGGSSSS
  492.      On the Personal Iris, when using PPPPMMMM____SSSSIIIIZZZZEEEE with values 8 or 16, the width
  493.      of the rectangle drawn must be a multiple of 4 for 8-bit packed writes,
  494.      and a multiple of 2 for 16-bit packed writes.
  495.  
  496.      On the IRIS-4D RealityEngine model PPPPMMMM____SSSSIIIIZZZZEEEE of 24 is not supported in
  497.      color map mode. PPPPMMMM____SSSSIIIIZZZZEEEE of 32 in conjunction with a non zero PPPPMMMM____OOOOFFFFFFFFSSSSEEEETTTT is
  498.      not supported as well in color map mode.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.                                                                         PPPPaaaaggggeeee 8888
  526.  
  527.  
  528.  
  529.